1. Technical Field of the Invention
The invention relates to the field of advanced interfaces for input-output devices of a computer system, and more particularly, to a technique for simulating hardware interrupts in a multiprocessor computing environment especially while emulating hardware devices using software modules that are compliant with the Intelligent Input-Output (I20) standard.
2. Description of Related Art
The use of personal computers has expanded remarkably in recent years. Modern personal computers are generally characterized by a flexible hardware architecture and a relatively open software architecture. The use of standardized bus architectures (such as the PCI Bus and the Fibre Channel) has permitted users to customize their personal computers to meet their particular hardware and software needs. In consequence, a variety of input and output devices are available for most popular personal computers.
As the computational power of personal computers has grown, in many instances, high-end personal computers have become relatively indistinguishable from servers and workstations. Certain workstations are being powered by multiple microprocessors. The predominant difference between personal computers and workstations are the different operating systems that are commonly used in the two environments. On personal computers, the Microsoft Windows environment is currently the dominant operating system. In contrast many servers and workstations use variants of the Unix operating system (e.g., the Solaris operating system used on Sun workstations). Increasingly, there has been demand in the marketplace for multiprocessor machines that run under Microsoft""s Windows NT 32-bit operating system.
As mentioned earlier, one of the reasons for the growing popularity of personal computers, servers and workstations has been their capability for customization. Modern personal computers, servers and workstations can be customized in terms of both their hardware as well as their software. From a hardware viewpoint, the customization of personal computers, servers and workstations most commonly involves the selection and installation of one or more specialized input-output devices, e.g., keyboards, monitors, printers, storage devices, etc. From a software viewpoint, personal computers, servers and workstations are customized by installing and integrating various application programs.
It has been found desirable by both vendors as well as consumers to have a large selection of reliable input/output (I/O) devices. The availability of such a wide range of input-output devices increases the size of the market of potential purchasers of such devices by providing the customization capabilities desired by a larger pool of potential purchasers. Furthermore, it has been found desirable for input-output devices to embody a greater degree of xe2x80x9cintelligence.xe2x80x9d Thus, for example, it would be desirable for each input-output device to be able to perform its function without needing active supervision or interaction with the central processing units (CPUs) of the computer system.
Most input-output devices generate responses and initiate communications with the CPU by generating an interrupt either in hardware or in software. Such an interrupt typically causes the CPU to suspend execution of whatever task it is currently executing in order to respond to the I/O device generating the interrupt. It has been recognized by experts in the field that one of the most significant reasons for the reduction in the performance of computer systems is the performance impact resulting from input-output interrupts to the CPU.
Another key problem area in I/O processing is the current necessity of creating, testing, integrating and supporting unique device drivers for each combination of I/O device and operating system that a vendor desires to support. For example, it has been reported that the recently-introduced Microsoft Windows98 operating system has been bundled with over 1200 device drivers. It has therefore been found desirable to find techniques for implementing cross-platform intelligent I/O that can broaden the availability and application of reliable, intelligent I/O devices.
It has also been found desirable to have a methodology and a standardized architecture for intelligent I/O in which low-level interrupts can be off-loaded from the CPU to one or more dedicated I/O processors (IOPs) that have optimized to handle I/O tasks. It would also be useful if multiple independent IOPs could communicate with each other and with the CPUs using a message-passing protocol. The development of a standardized intelligent I/O architecture would greatly improve I/O and CPU performance in high-bandwidth applications such as networked video, groupware and client/server processing.
It has also been found desirable to have an architectural model that does not constrain the processor upon which a specific I/O task executes and can thus be implemented on a single-processor, multiprocessor or clustered computer system. With the proliferation of network operating systems (such as NetWare 4, Windows NT Server and UnixWare), the number of device drivers that need to be written, tested, integrated and supported has vastly expanded. This is because the traditional technique for writing device drivers requires vendors to create a new device driver for every unique combination of operating system and hardware device that is to be supported.
It has therefore been found desirable to define a development environment for creating device drivers that are portable across multiple operating systems and host platforms. It would further be desirable if the task of creating, testing, integrating and supporting unique device drivers for every combination of operating system and device could be reduced by defining a standard interface and having the operating system designer and the device manufacturer share the task of writing and debugging each device driver.
It is thus desirable for an operating system vendor to be able to write a single device driver for each class of device that is compatible with a standardized device driver interface. Likewise, it has also been found desirable for the manufacturer of an I/O device to be able to write a single standardized device driver for the I/O device that may be used with any operating system supporting the I2O interface standard. Such an open, standards-based approach to device driver design can facilitate the rapid development of a new generation of portable and intelligent I/O solutions for personal computers and workstations.
It has further been found desirable to be able to emulate hardware devices in software while complying with the I2O interface standard. It would be an additional advantage if such emulation could be facilitated on computer systems embodying a multiprocessor architecture and running under the Microsoft Windows NT operating system.
In one aspect, the present invention is a mechanism for simulating a hardware interrupt on one microprocessor while a corresponding input/output (I/O) device is emulated in software on a different microprocessor in the same computer system. The emulated I/O device is controlled by a modular device driver. The modular device driver is based upon the Intelligent Input/Output (I2O) split device driver development model in which the functionality of a device driver is partitioned into at least two software modules, one of which is an operating-system-specific Operating System Services Module (OSM) while another is an I/O-device-specific Hardware Device Module (HDM). A single computer system may have multiple OSMs and/or HDMs.
The I2O split driver model defines a standardized messaging protocol for intercommunication between associated pairs of OSM and HDM software modules. Messages from one or more of the OSMs are maintained in an inbound message queue while messages from one or more of the HDMs are maintained in an outbound message queue. Messages between the various software modules are exchanged over a shared communications layer.
In another aspect, the present invention is a technique for providing hardware interrupt simulation using the Interprocessor Interrupt (IPI) mechanism of the local Advanced Programmable Interrupt Controller (APIC) on a Symmetric Multiprocessor (SMP) System running the Microsoft Windows NT operating system. The hardware interrupt simulation is performed by first determining the Interrupt Request (IRQ) vector that is associated with a specific system device driver. In the case of a device being emulated, this determination of the IRQ vector is done by intercepting the messages from the interrupt invoking procedure.
The IRQ vector provides a pointer to the device driver""s Interrupt Service Routine (ISR). After the device driver""s ISR has been connected to the appropriate interrupt vector entry in the Interrupt Descriptor Table (IDT), the vector number is combined with the local APIC constant and followed by a 32-bit write operation into the lower part of the Interrupt Control Register (ICRL) of the local APIC.